IBIS Macromodel Task Group Meeting date: 21 June 2016 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM * Luis Armenta Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner * Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - Arpad asked if we should cancel the July 5th meeting because people might be away the week of the July 4th holiday. Radek moved to cancel the July 5th meeting. Walter seconded. No one was opposed. The July 5th meeting will not be held. - As this was Kevin Li's first time joining the ATM meeting, Arpad asked him to briefly introduce himself. Kevin said he works for Synopsys' SI PI group. He works on generating IBIS and AMI models and is interested in the latest discussions on C_comp and Buffer model creation in general. ------------- Review of ARs: - Walter to update the DUT_ref_term BIRD draft to produce draft 2. - Done. Draft 2 was emailed to the list and posted to the archives. - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Mike L.: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: DUT_ref_term BIRD Draft 2: - Walter: [sharing draft 2 of the BIRD] - Added Ext_ref as a possible selection for DUT_ref_term (as decided in last week's meeting). - Removed the superfluous initial phrase "If ... [* Reference] is not 0.0" from the first sentence of the "Other Notes:" section, as Bob had suggested. - Walter: [reviewing his email to which draft 2 was attached] - Note that Ext_ref is not forbidden for drivers. The IBIS spec only says: "Figure 16 - [External Reference] - (used only for non-driver modes)" - Nothing prevents Ext_ref from being used within a driver. I'm not sure what the parser would do with it. - Walter: [ reviewing Bob's spreadsheet (also attached to the email)] - I recommend using the same terminal names used by [Receiver Thresholds]. - I'm going to propose that the Interconnect BIRD be changed to use them as well. - Walter: We could use "Reference_terminal" instead of "DUT_ref_term" for the subparameter's name. - Bob: I prefer a shorter name, though I understand the confusion because "term" could be short for termination. - Arpad: I like "Reference_terminal" because it is clearer. - Bob: I would go with "Ref_terminal," since its possible values are the *_ref terminals. - Walter: Motion to change DUT_ref_term to Ref_terminal. - Arpad: Second. [no one opposed, though Bob noted his preference for Ref_term] - Discussion: Radek said he still disagreed with the paragraph in the BIRD that describes adding the value of the [* Reference] keyword to the voltages measured relative to the Ref_terminal. He said if the keywords are the voltages relative to the reference terminal, then how could [* Reference] be non-zero for the terminal that served as the Ref_terminal? Walter reviewed the IBIS spec's figure 16 [External Reference]. He said the [* Reference] keywords defined the voltage between the corresponding terminal and the test fixture ground (ground symbol in Figure 16) during the DUT measurement. At simulation time, the difference between any local node and the Ref_terminal is computed and then the [* Reference] value is added in as the offset. Arpad and Radek said the problem was that the v(t) tables in the IBIS file contained a voltage column that was relative to that test fixture ground (ground symbol). Walter said that as soon as you compute the difference between the pad and the Ref_terminal at simulation time, you add in the [* Reference] offset and end up with a value you can use to go into the v(t) table (and other things like Vinl and Vinh thresholds, etc.) Curtis said he thought of this step as converting the local relative measurements at simulation time (DIA) back to the "absolute" values that existed at DUT time because those are what are found in the IBIS file. Walter agreed and said this was a nice way to describe it. Walter also noted that the v(t) table itself is not really a problem at simulation time because it is only used to generated the K(t) scalers, and this is done with DUT conditions. Radek said we had to be careful because things are simple with a basic C_comp, but once we have a more complicated block these assumptions could break down. He said the fixed offset approach worked for the simple case, but he considered it to be compensating for the fact that the test_fixture/local ground terminal was "removed" from the model. He said that in the most general case we really want to have that local ground terminal available to the model. He said in the most general case you might have all 5 [* Reference] values non-zero. In that case you would still need a separate terminal for the actual local ground. - Discussion: Walter agreed with Radek's point about the most general case. He said that in our discussion on this topic we all agreed that at simulation time (device in action), you can't really measure the voltage between buffer terminals and some far away test fixture ground. Yet, for DUT measurements we assume we can. In practice this is because there really must be some other Pin on the component's package that can be used to connect to "ground." It may not be one of the four rail terminals we've identified in the IBIS [Model], but we know there must be some ground pin local to the component for any of these measurements to make any sense. For example, if you have PECL and the [Model] says the rail voltages ([* Reference]) are not zero, there must be some Pin which is ground and relative to which they are not zero. It's just not a pin that takes a part in the operation of the particular buffer. Walter reiterated a suggestion that we ought to have a new additional terminal called a reference terminal (e.g. DUT_ref), just like we have Ext_ref, Pullup_ref, etc., added to the [Pin Mapping] section. With that new column in [Pin Mapping] you could specify a Pin (bus label) which is in fact the local ground for the [Model]. Radek said this was what he has been advocating, too. Walter reviewed an alternate version of the BIRD he had been drafting, which contained a new model terminal DUT_ref that you can add to [Pin Mapping] and add to the list of terminals that can be assigned to the Ref_terminal, and its corresponding [* Reference] is by definition always 0.0V. DUT_ref is used to identify the Pin in the system that is connected to the ground. Radek again agreed and said that one could do it this way by extending [Pin Mapping], or could do it with the additional [Pin Reference] keyword Walter had described in the alternative Pin Reference BIRD. He noted that one inconvenience of extending [Pin Mapping] was that the sixth column 'Ext_ref' was optional and maintaining backward compatibility by adding a seventh column 'Dut_ref' would put a more important column (7) after a less important column (6). Bob asked why declare a DUT_ref if it's always known to be 0.0V? Radek said he hadn't thought it through fully, but that in the most general case you might have a situation where the DUT_ref terminal's [* Reference] was non-zero and the other reference terminals were considered connected to it if they shared the same value in their [* Reference]. Bob said he considered DUT_ref's [* Reference] to be 0.0V fixed, and that all the other [* Reference] values were all relative to that 0.0. Arpad asked if the existing reserved terminal name A_gnd might be used for this purpose instead of inventing a new terminal name. Radek and Walter thought that this could be done. Radek noted that we would need to extend A_gnd beyond the Multi-Lingual Model Extensions context. - Discussion: Arpad asked what remained to do to complete discussions and move on to formalizing the BIRD draft. Walter asked if we agreed that we would go with the DUT_ref that is always 0.0V? If so, in a power aware simulation we need a way to specify what Pin or bus label serves as that reference. In that case we need to add something to [Pin Mapping] to define it, or we could use the [Pin Reference] proposal for that association and make it optional and only used for cases in which none of the existing five [* Reference] values were 0.0. Radek agreed. Walter said he and Radek agreed, if any of the five existing [* Reference] values is 0.0, then the corresponding terminal can be the reference terminal for simulation. If not, then the model maker needs a way to assign the Pin that will serve as the DUT_ref terminal. Walter said he would write up these changes. Bob said he saw no value in adding a specification of something that is always 0.0V. He felt this was already implicit, and that the other [* Reference] values are by definition ideal fixed offsets from it, so any one of their corresponding terminals could be used as a reference. - Arpad: Thank you all for joining. ------------- Next meeting: 28 June 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives